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Abstract 


RFC 7668 describes the adaptation of IPv6 over Low-Power Wireless Personal Area Network 
(6LOWPAN) techniques to enable IPv6 over Bluetooth Low Energy (Bluetooth LE) networks that 
follow the star topology. However, recent Bluetooth specifications allow the formation of 
extended topologies as well. This document specifies mechanisms that are needed to enable IPv6 
mesh over Bluetooth LE links established by using the Bluetooth Internet Protocol Support Profile 
(IPSP). This document does not specify the routing protocol to be used in an IPv6 mesh over 
Bluetooth LE links. 
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1. Introduction 


Bluetooth Low Energy (hereinafter, Bluetooth LE) was first introduced in the Bluetooth 4.0 
specification. Bluetooth LE (which has been marketed as Bluetooth Smart) is a low-power wireless 
technology designed for short-range control and monitoring applications. Bluetooth LE is 
currently implemented in a wide range of consumer electronics devices, such as smartphones 
and wearable devices. Given the high potential of this technology for the Internet of Things, the 
Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have produced specifications in 
order to enable IPv6 over Bluetooth LE, such as the Internet Protocol Support Profile (IPSP) [IPSP] 
and RFC 7668 [RFC7668], respectively. Bluetooth 4.0 only supports Bluetooth LE networks that 
follow the star topology. As a consequence, RFC 7668 [RFC7668] was specifically developed and 
optimized for that type of network topology. However, the functionality described in RFC 7668 
[RFC7668] is not sufficient and would fail to enable an IPv6 mesh over Bluetooth LE links. This 
document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth LE links. 
This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE 
links. 


1.1. Terminology and Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


The terms "6LOWPAN Node" (6LN), "6LOWPAN Router" (6LR), and "6LOWPAN Border Router" 
(6LBR) are defined as in [RFC6775], with an addition that Bluetooth LE central and Bluetooth LE 
peripheral (see Section 2) can both be adopted by a 6LN, a 6LR, or a 6LBR. 


2. Bluetooth LE Networks and the IPSP 


Bluetooth LE defines two Generic Access Profile (GAP) roles of relevance herein: the Bluetooth LE 
central role and the Bluetooth LE peripheral role. In Bluetooth 4.0, a device in the central role, 
which is called "central" from now on, was able to manage multiple simultaneous connections 
with a number of devices in the peripheral role, called "peripherals" hereinafter. Bluetooth 4.1 
(now deprecated) introduced the possibility for a peripheral to be connected to more than one 
central simultaneously, therefore allowing extended topologies beyond the star topology fora 
Bluetooth LE network [BTCorev4.1]. In addition, a device may simultaneously be a central in a set 
of link-layer connections, as well as a peripheral in others. 


On the other hand, the IPSP enables discovery of IP-enabled devices and the establishment of a 
link-layer connection for transporting IPv6 packets. The IPSP defines the Node and Router roles 
for devices that consume/originate IPv6 packets and for devices that can route IPv6 packets, 
respectively. Consistent with Bluetooth 4.1, Bluetooth 4.2 [BTCorev4.2], and subsequent Bluetooth 
versions, a device may implement both roles simultaneously. 
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This document assumes a mesh network composed of Bluetooth LE links, where link-layer 
connections are established between neighboring IPv6-enabled devices (see Section 3.3.2, item 3.b, 
and an example in Appendix A). The IPv6 forwarding devices of the mesh have to implement both 
IPSP Node and Router roles, while simpler leaf-only nodes can implement only the Node role. In 
an IPv6 mesh over Bluetooth LE links, a node is a neighbor of another node, and vice versa, if a 
link-layer connection has been established between both by using the IPSP functionality for 
discovery and link-layer connection establishment for IPv6 packet transport. 


3. Specification of IPv6 Mesh over Bluetooth LE Links 


3.1. Protocol Stack 


Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth LE links. The core Bluetooth LE 
protocol stack comprises two main sections: the Controller and the Host. The former includes the 
Physical Layer and the Link Layer, whereas the latter is composed of the Logical Link Control and 
Adaptation Protocol (L2CAP), the Attribute Protocol (ATT), and the Generic Attribute Profile 
(GATT). The Host and the Controller sections are connected by means of the Host-Controller 
Interface (HCI). A device that supports the IPSP Node role instantiates one Internet Protocol 
Support Service (IPSS), which runs atop GATT. The protocol stack shown in Figure 1 shows two 
main differences with the IPv6 over Bluetooth LE stack in [RFC7668]: 


a) the adaptation layer below IPv6 (labeled as "6Lo for IPv6 mesh over Bluetooth LE") is now 
adapted for IPv6 mesh over Bluetooth LE links, and 


b) the protocol stack for IPv6 mesh over Bluetooth LE links includes IPv6 routing 


functionality. 

+------------------------------------ + 

| Application | 
+--------- + 4+------------------------------------ + 
| IPSS | UDP/TCP/other l 
+--------- + +------------------------------------ + 
| GATT | | IPv6 |routing| | 
+--------- + +------------------------------------ + 
| ATT | | 6Lo for IPv6 mesh over Bluetooth LE} 
+--------- +--+------------------------------------ + 
| Bluetooth LE L2CAP | 

HEL Se F E i i BE moa 

| Bluetooth LE Link Layer 
+------------------------------------------------- + 
| Bluetooth LE Physical Layer 
+------------------------------------------------- + 


Figure 1: Protocol Stack for IPv6 Mesh over Bluetooth LE Links 


Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes. Excluding the L2CAP header of 4 
bytes, a protocol data unit (PDU) size of 247 bytes is available for the layer above L2CAP. (Note: 
Earlier Bluetooth LE versions offered a maximum amount of 23 bytes for the layer atop L2CAP.,) 
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The L2CAP provides a fragmentation and reassembly solution for transmitting or receiving larger 
PDUs. At each link, the IPSP defines means for negotiating a link-layer connection that provides 
an MTU of 1280 octets or higher for the IPv6 layer [IPSP]. As per the present specification, the MTU 
size for IPv6 mesh over BLE links is 1280 octets. 


Similarly to [RFC7668], fragmentation functionality from 6LOWPAN standards is not used for IPv6 
mesh over Bluetooth LE links. Bluetooth LE's fragmentation support provided by L2CAP is used. 


3.2. Subnet Model 


For IPv6 mesh over Bluetooth LE links, a multilink model has been chosen, as further illustrated in 
Figure 2. As IPv6 over Bluetooth LE is intended for constrained nodes and for Internet of Things 
use cases and environments, the complexity of implementing a separate subnet on each 
peripheral-central link and routing between the subnets appears to be excessive. In this 
specification, the benefits of treating the collection of point-to-point links between a central and 
its connected peripherals as a single multilink subnet rather than a multiplicity of separate 
subnets are considered to outweigh the multilink model's drawbacks as described in [RFC4903]. 
With the multilink subnet model, the routers have to take on the responsibility of tracking the 
multicast state and forwarding multicast in a loop-free manner. Note that the route-over 
functionality defined in [RFC6775] is essential to enabling the multilink subnet model for IPv6 
mesh over Bluetooth LE links. 


/ 
/ 
6LR 6LN 6LN / 
\ \ \ / 
\ \ \ / 
6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet 
< link- -> <---Link--->/<--Link->/ 
/ / \ 
6LN ---- 6LR ----- 6LR \ 
\ 
\ 
ee ree SUD Cte == ae ><---- IPv6 connection --> 


to the Internet 
Figure 2: Example of an IPv6 Mesh over a Bluetooth LE Network Connected to the Internet 


One or more 6LBRs are connected to the Internet. 6LNs are connected to the network througha 
6LR or a 6LBR. Note that in some scenarios and/or for some time intervals, a 6LR may remain at 
the edge of the network (e.g., the top left node in Figure 2). This may happen when a 6LR has no 
neighboring 6LNs. A single global unicast prefix is used on the whole subnet. 


IPv6 mesh over Bluetooth LE links MUST follow a route-over approach. This document does not 
specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links. 
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3.3. Link Model 


3.3.1. Stateless Address Autoconfiguration 


6LN, 6LR, and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE links are configured as per 
Section 3.2.2 of [RFC7668]. 


Multihop Duplicate Address Detection (DAD) functionality as defined in Section 8.2 of [RFC6775] 
and updated by [RFC8505], or some substitute mechanism (see Section 3.3.2), MAY be supported. 


3.3.2. Neighbor Discovery 


"Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks 
(6LOWPANs)" [RFC6775], subsequently updated by "Registration Extensions for IPv6 over Low- 
Power Wireless Personal Area Network (6LOWPAN) Neighbor Discovery" [RFC8505], describes the 
neighbor discovery functionality adapted for use in several 6LOWPAN topologies, including the 
mesh topology. The route-over functionality of [RFC6775] and [RFC8505] MUST be supported. 


The following aspects of the Neighbor Discovery optimizations for 6LoWPAN [RFC6775] [RFC8505] 
are applicable to Bluetooth LE 6LNs: 


1. A Bluetooth LE 6LN MUST register its non-link-local addresses with its routers by sending a 
Neighbor Solicitation (NS) message with the Extended Address Registration Option (EARO) 
and process the Neighbor Advertisement (NA) accordingly. The EARO option includes a 
Registration Ownership Verifier (ROVR) field [RFC8505]. In the case of Bluetooth LE, by 
default, the ROVR field is filled with the 48-bit device address used by the Bluetooth LE node 
converted into 64-bit Modified EUI-64 format [RFC4291]. Optionally, a cryptographic ID (see 
RFC 8928 [RFC8928]) MAY be placed in the ROVR field. If a cryptographic ID is used, address 
registration and multihop DAD formats and procedures defined in [RFC8928] MUST be used 
unless an alternative mechanism offering equivalent protection is used. 


As per [RFC8505], a 6LN link-local address does not need to be unique in the multilink subnet. 
A link-local address only needs to be unique from the perspective of the two nodes that use it 
to communicate (e.g., the 6LN and the 6LR in an NS/NA exchange). Therefore, the exchange of 
Extended Duplicate Address Request (EDAR) and Extended Duplicate Address Confirmation 
(EDAC) messages between the 6LR and a 6LBR, which ensures that an address is unique across 
the domain covered by the 6LBR, does not need to take place for link-local addresses. 


If the 6LN registers multiple addresses that are not based on the Bluetooth device address 
using the same compression context, the header compression efficiency may decrease, since 
only the last registered address can be fully elided (see Section 3.2.4 of [RFC7668]). 


2. For sending Router Solicitations and processing Router Advertisements, the hosts that 
participate in an IPv6 mesh over BLE MUST, respectively, follow Sections 5.3 and 5.4 of 
[RFC6775], and Section 5.6 of [RFC8505]. 

3. The router behavior for 6LRs and 6LBRs is described in Section 6 of [RFC6775] and updated by 
[RFC8505]. However, as per this specification: 

a. Routers SHALL NOT use multicast NSs to discover other routers’ link-layer addresses. 
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b. As per Section 6.2 of [RFC6775], in a dynamic configuration scenario, a 6LR comes up as a 
non-router and waits to receive a Router Advertisement for configuring its own interface 
address first before setting its interfaces to advertising interfaces and turning into a router. 
In order to support such an operation in an IPv6 mesh over Bluetooth LE links, a 6LR first 
uses the IPSP Node role only. Once the 6LR has established a connection with another node 
currently running as a router and receives a Router Advertisement from that router, the 
6LR configures its own interface address, turns into a router, and runs as an IPSP Router. In 
contrast with a 6LR, a 6LBR uses the IPSP Router role since the 6LBR is initialized; that is, 
the 6LBR uses both the IPSP Node and IPSP Router roles at all times. See an example in 
Appendix B. 


4. Border router behavior is described in Section 7 of [RFC6775] and updated by [RFC8505]. 


[RFC6775] defines substitutable mechanisms for distributing prefixes and context 
information (Section 8.1 of [RFC6775]), as well as for duplicate address detection across a 
route-over 6LOWPAN (Section 8.2 of [RFC6775]). [RFC8505] updates those mechanisms and the 
related message formats. Implementations of this specification MUST either support the 
features described in Sections 8.1 and 8.2 of [RFC6775], as updated by [RFC8505] or some 
alternative ("substitute") mechanism. 


3.3.3. Header Compression 


Header compression as defined in RFC 6282 [RFC6282], which specifies the compression format 
for IPv6 datagrams on top of IEEE 802.15.4, is REQUIRED as the basis for IPv6 header compression 
on top of Bluetooth LE. All headers MUST be compressed according to RFC 6282 [RFC6282] 
encoding formats. 


To enable efficient header compression, when the 6LBR sends a Router Advertisement, it MAY 
include a 6LOWPAN Context Option (6CO) [RFC6775] matching each address prefix advertised via 
a Prefix Information Option (PIO) [RFC4861] for use in stateless address autoconfiguration. Note 
that 6CO is not needed for context-based compression when the context is pre-provisioned or 
provided by out-of-band means as, in these cases, the in-band indication (6CO) becomes 
superfluous. 


The specific optimizations of [RFC7668] for header compression, which exploited the star 
topology and Address Registration Option (ARO) (note that the latter has been updated by EARO 
as per [RFC8505]), cannot be generalized in an IPv6 mesh over Bluetooth LE links. Still, a subset of 
those optimizations can be applied in some cases in sucha network. These cases comprise link- 
local interactions, non-link-local packet transmissions originated by a 6LN (i.e., the first hop from 
a 6LN), and non-link-local packets intended for a 6LN that are originated or forwarded by a 
neighbor of that 6LN (i.e., the last hop toward a 6LN). For all other packet transmissions, context- 
based compression MAY be used. 


When a device transmits a packet to a neighbor, the sender MUST fully elide the source Interface 
Identifier (IID) if the source IPv6 address is the link-local address based on the sender's Bluetooth 
device address (SAC=0, SAM=11). The sender also MUST fully elide the destination IPv6 address if it 
is the link-local address based on the neighbor's Bluetooth device address (DAC=0, DAM=11). 
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When a 6LN transmits a packet with a non-link-local source address that the 6LN has registered 
with EARO in the next-hop router for the indicated prefix, the source address MUST be fully elided 
if it is the latest address that the 6LN has registered for the indicated prefix (SAC=1, SAM=11). If the 
source non-link-local address is not the latest registered by the 6LN and the first 48 bits of the IID 
match the latest address are registered by the 6LN, then the last 16 bits of the IID SHALL be carried 
inline (SAC=1, SAM=10). Otherwise, if the first 48 bits of the IID do not match, then the 64 bits of the 
IID SHALL be fully carried inline (SAC=1, SAM=01). 


When a router transmits a packet to a neighboring 6LN with a non-link-local destination address, 
the router MUST fully elide the destination IPv6 address if the destination address is the latest 
registered by the 6LN with EARO for the indicated context (DAC=1, DAM=11). If the destination 
address is a non-link-local address and not the latest registered and if the first 48 bits of the IID 
match those of the latest registered address, then the last 16 bits of the IID SHALL be carried inline 
(DAC=1, DAM=10). Otherwise, if the first 48 bits of the IID do not match, then the 64 bits of the IID 
SHALL be fully carried in-line (DAC=1, DAM=01). 


3.3.4. Unicast and Multicast Mapping 


The Bluetooth LE Link Layer does not support multicast. Hence, traffic is always unicast between 
two Bluetooth LE neighboring nodes. If a node needs to send a multicast packet to several 
neighbors, it has to replicate the packet and unicast it on each link. However, this may not be 
energy efficient, and particular care must be taken if the node is battery powered. A router (i.e., a 
6LR or a 6LBR) MUST keep track of neighboring multicast listeners, and it MUST NOT forward 
multicast packets to neighbors that have not registered as listeners for multicast groups to which 
the packets are destined. 


4. IANA Considerations 


This document has no IANA actions. 


5. Security Considerations 
The security considerations in [RFC7668] apply. 


IPv6 mesh over BLE requires a routing protocol to find end-to-end paths. Unfortunately, the 
routing protocol may generate additional opportunities for threats and attacks to the network. 


RFC 7416 [RFC7416] provides a systematic overview of threats and attacks on the IPv6 Routing 
Protocol for Low-Power and Lossy Networks (RPL), as well as countermeasures. In that 
document, described threats and attacks comprise threats due to failures to authenticate, threats 
due to failure to keep routing information, threats and attacks on integrity, and threats and 
attacks on availability. Reported countermeasures comprise confidentiality attack, integrity 
attack, and availability attack countermeasures. 


While this specification does not state the routing protocol to be used in IPv6 mesh over Bluetooth 
LE links, the guidance of [RFC7416] is useful when RPL is used in such scenarios. Furthermore, 
such guidance may partly apply for other routing protocols as well. 
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The ROVR can be derived from the Bluetooth device address. However, such a ROVR can be 
spoofed; therefore, any node connected to the subnet and aware of a registered-address-to-ROVR 
mapping could perform address theft and impersonation attacks. Use of Address Protected 
Neighbor Discovery [RFC8928] provides protection against such attacks. 
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Appendix A. Bluetooth LE Connection Establishment Example 


This appendix provides an example of Bluetooth LE connection establishment and use of IPSP 
roles in an IPv6 mesh over BLE that uses dynamic configuration. The example follows text in 
Section 3.3.2, item 3.b. 


The example assumes a network with one 6LBR, two 6LRs, and three 6LNs, as shown in Figure 3. 
Connectivity between the 6LNs and the 6LBR is only possible via the 6LRs. 


The following text describes the different steps in the example as time evolves. Note that other 
sequences of events that may lead to the same final scenario are also possible. 


At the beginning, the 6LBR starts running as an IPSP router, whereas the rest of devices are not 
yet initialized (Step 1). Next, the 6LRs start running as IPSP nodes, i.e., they use Bluetooth LE 
advertisement packets to announce their presence and support of IPv6 capabilities (Step 2). The 
6LBR (already running as an IPSP router) discovers the presence of the 6LRs and establishes one 
Bluetooth LE connection with each 6LR (Step 3). After establishment of those link-layer 
connections (and after reception of Router Advertisements from the 6LBR), the 6LRs start 
operating as routers and also initiate the IPSP Router role (Step 4). (Note: whether the IPSP Node 
role is kept running simultaneously is an implementation decision). Then, 6LNs start running the 
IPSP Node role (Step 5). Finally, the 6LRs discover the presence of the 6LNs and establish 
connections with the latter (Step 6). 
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Step 1 
KKKKKK 
6LBR 
(IPSP: Router) 
6LR 6LR 
(not initialized) (not initialized) 
6LN 6LN 6LN 
(not initialized) (not initialized) (not initialized) 
Step 2 
KKKKKK 
6LBR 
(IPSP: Router) 
6LR 6LR 
(IPSP: Node) (IPSP: Node) 
6LN 6LN 6LN 
(not initialized) (not initialized) (not initialized) 
Step 3 
KKKKKK 
6LBR 
(IPSP: Router) 
Bluetooth LE connection --> / 3 
/ \ 
6LR 6LR 
(IPSP: Node) (IPSP: Node) 
6LN 6LN 6LN 
(not initialized) (not initialized) (not initialized) 
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Step 4 
KKKKKK 
6LBR 
(IPSP: Router) 
/ \ 
i; \ 
6LR 6LR 
(IPSP: Router) (IPSP: Router) 
6LN 6LN 6LN 
(not initialized) (not initialized) (not initialized) 
Step 5 
KKKKKK 
6LBR 
(IPSP: Router) 
/ \ 
/ \ 
6LR 6LR 
(IPSP: Router) (IPSP: Router) 
6LN 6LN 6LN 
(IPSP: Node) (IPSP: Node) (IPSP: Node) 
Step 6 
KKKKKK 
6LBR 
(IPSP: Router) 
/ \ 
/ \ 
6LR 6LR 
(IPSP: Router) (IPSP: Router) 
/ \ / \ 
/ \ / \ 
if \ / Ñ 
6LN 6LN 6LN 
(IPSP: Node) (IPSP: Node) (IPSP: Node) 


Figure 3: Example of Connection Establishment and Use of IPSP Roles in an IPv6 Mesh over 
Bluetooth LE Links 
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Appendix B. Node-Joining Procedure 


This appendix provides a diagram that illustrates the node-joining procedure. First of all, the 
joining node advertises its presence in order to allow establishment of Bluetooth LE connections 
with neighbors that already belong to a network. The neighbors typically run as a 6LR oras a 
6LBR. After Bluetooth LE connection establishment, the joining node starts acting as a 6LN. 


Figure 4 shows the sequence of messages that are exchanged by the 6LN anda neighboring 6LR 
that already belongs to the network after the establishment of a Bluetooth LE connection 
between both devices. Initially, the 6LN sends a Router Solicitation (RS) message (1). Then, the 6LR 
replies with an RA, which includes the PIO (2). After discovering the non-link-local prefix in use in 
the network, the 6LN creates its non-link-local address and registers that address with EARO (3) in 
the 6LR, and then multihop DAD is performed (4). The next step is the transmission of the NA 
message sent by the 6LR in response to the NS previously sent by the 6LN (5). If the non-link-local 
address of the 6LN has been successfully validated, the 6LN can operate as a member of the 
network it has joined. 


(1) UN eee emer ee > 6LR 
(2) OEN < (RA PIO) — GR 
(3) 6LN ----(NS-EARO)--> 6LR 
(4) [Multihop DAD procedure] 
(5) OINI (NA 6LR 


Figure 4: Message Exchange Diagram for a Joining Node 
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